home *** CD-ROM | disk | FTP | other *** search
/ Graphics Plus / Graphics Plus.iso / msdos / raytrace / dbwrend / read.me < prev   
Text File  |  1989-11-08  |  12KB  |  286 lines

  1. This IBM version of DBW_Render was ported from the AMIGA by me:
  2.  
  3.     John H. Lowery
  4.     25 Mirror Place
  5.     Oak Ridge, NJ 07438
  6.  
  7. Comments, questions and suggestions concerning the IBM version
  8. should be directed there.  Please do, however, become a registered
  9. user by send the suggested $18 shareware donation to:
  10.  
  11.     William T. Baldridge
  12.     2650 Sherwood Lane
  13.     Pueblo, CO 81005
  14.  
  15. who now administers DBW_Render for the author, David B. Wecker.
  16.  
  17. Please indicate that you are using the IBM-PC version 1.02, rather 
  18. than the AMIGA version.
  19.  
  20. If you develop any particularly neat pictures, please consider 
  21. uploading them ( in .DAT input file format, compressed with PKZIP or
  22. ARC, as applicable ) to the bulletin board from which you obtained 
  23. this program.  
  24.  
  25. I will make a point of posting the latest version of DBW_Render for
  26. the IBM, and interesting input files, on the following BBS's:
  27.  
  28.     Chuck's Attempt (Sparta,  NJ)   (201) 729-2602
  29.         Great Graphics  (Rahway,  NJ)   (201) 396-9571
  30.     Just Programs   (Roselle, NJ)   (201) 298-9098
  31.     The Invention Factory (NY, NY)  (212) 431-1273
  32.  
  33. .. and any other BBS that indicates an interest.  
  34.  
  35. Please note that a version 2.0 of DBW_Render has become available
  36. for the AMIGA, but has not been released as shareware, so no IBM
  37. version is available (at this time).
  38.  
  39. The following comments are culled from those provided with the 
  40. AMIGA version of the software by Dave Wecker, but are equally 
  41. applicable to the IBM version:
  42.  
  43.  
  44. -> What is the best way to "design" a picture?
  45.  
  46. In your .DAT file set the following parameters:
  47.  
  48.     a.    no transmission (everything opaque).
  49.     b.    no "mirrors" (use low reflection/diffusion levels).
  50.     c.    use only 1 light source.
  51.     d.    make the light source infinitely far away ("l" not "L").
  52.     e.    use a small numbers of objects.
  53.     f.    no anti aliasing
  54.  
  55. This will allow you to prototype pictures VERY quickly (minutes not hours).
  56. BTW: this is why JUGGLER only took its author 1 hour/frame to compute it used
  57. items a,c,d and e,f (depending on def. of "small")
  58.  
  59. -> I seem to be using A LOT of stack when there are mirrored objects.. why?
  60.  
  61. If you have two (or more) highly reflective spheres (mirrored) and a bright
  62. light sources, you probably STILL run out of stack because you have to bounce
  63. the light back and forth between them for a LONG time (not infinite do to the
  64. inverse square law)... you can patch the file RAY.C changing all occurrences
  65. of:
  66.      max_runs = 32767;
  67.  
  68. to a smaller number (somewhere between 30 and 300 for example). This will set a
  69. much smaller maximum recursion value (and thus much smaller stack usage).
  70.  
  71. ->    How do I go about positioning the eye/camera...
  72.  
  73. The easiest thing to do is to set the center of your image at (0,0,0). This is
  74. what is done in the GLASS.DAT example. The eye is positioned at:
  75.  
  76.     (30,180,200) looking in the direction of (-50,-320,-350)
  77.  
  78. Ok.. so how does this give us (0,0,0)? Well, if you start at the eye and add
  79. the direction vector you get (-20,-180,-150). It turns out that if you go 57%
  80. of the way along the direction vector you get (0,0,0)!!! So you are looking
  81. down and to the left through the origin and then 150 units further! By
  82. adjusting this distance you can magnify or reduce the entire image.
  83.  
  84. At the tip of the vector you have 256 units in X visible and 170 units in Y
  85. visible. This defines a viewing "cone" (which you can draw the lines out to).
  86. But for example, in the plane of the screen (Z = 0), you have visible:
  87.  
  88.     x: -73 to +73        (57% of 256)
  89.     y: -48 to +48        (57% of 170)
  90.  
  91. You can make this calculation for any desired depth.
  92.  
  93. ->    Objects are getting FUZZ even when they have 0.0 "fuzziness"...
  94.  
  95. Remember that if you don't give the program enough time to run in, it will
  96. "smear" objects by using the AI algorithms to guess at pixel values. Try to
  97. give a small strip of the picture an infinite amount (999.0 hours) to run in
  98. and you should see all pseudo-fuzz go away.
  99.  
  100. ->    What EXACTLY do the AI heuristics do?
  101.  
  102. Most of the "guess-work" happens in the "ray.c" module. First of all, I keep a
  103. cache of 9 lines (centered on the current line). This is used when the program
  104. runs out of time on a line and needs to guess at a pixels value. Routine
  105. "guess" calls "guess2" to scan out from the current pixel looking for computed
  106. pixels which are averaged for a "best guess".
  107.  
  108. When you set a resolution (using "R" in the .dat file), an initial estimate is
  109. made of how much time per scan line will be allowed. Pixels that are easy to
  110. compute (max_runs = 10) are computed first. If we still have time (curtime <=
  111. nxttime) or we haven't computed enough pixels (pixelcompute <= compmin
  112. (described below)) we randomly pick pixels at full computational level
  113. (max_runs = 32767) until either of the two previous conditions are met (or all
  114. pixels on a line have been computed).
  115.  
  116. Here is where the heuristics come in. At the end of a scan line the following
  117. estimates are made:
  118.  
  119. 1.    The next scan line will be allowed to have time of:
  120.         buftime      - normal time for a scanline
  121.           + xtrtime/8 - "extra" time: either not used by previous scan
  122.             lines (all pixels computed), or negative time (if
  123.             previous scanlines used too much time).
  124. 2.    compthresh = (2/3) * pixelcompute
  125.         This is the threshold at which max_runs switches over from
  126.         10 to 32767 (recursion level). pixelcompute is the total
  127.         number of pixels computed on prev scanline.
  128. 3.    compmin = (9/10) * pixelcompute
  129.         This many pixels MUST be computed (even if we run out
  130.         of time (this is how xtrtime can become negative)).
  131.  
  132. These estimates let us adaptively change how we decide the number of pixels 
  133. per line to compute. All pixels are chosen randomly to keep patterning out 
  134. of the picture.
  135.  
  136. ->    The General License states that any derivative must fall under the
  137.     terms of the license, does this mean that all pictiures created fall
  138.     under the terms of the license?
  139.  
  140. No! The License only covers derivates of the CODE. Any pictures you create are
  141. yours to do with as you please.
  142.  
  143. ->    Can you explain "Global index of refraction"?
  144.  
  145. It's just what the documentation says... the index of the "air". For instance,
  146. if you start increasing this value you can make the picture look like everyting
  147. is under water (or embedded in glass).
  148.  
  149. ->    Where should I set the anti aliasing parameters?
  150.  
  151. First read the documentation on the "A" setting, it's very detailed. Things to
  152. remember:
  153.  
  154. 1.    This parameter will help you get rid of the dreaded "jaggies"
  155.     (jagged diagonal lines).
  156.  
  157. 2.    If you set the COUNT to 4 each picture will take MINIMALLY
  158.     4 times as long to compute. This is because you are now
  159.     sending at LEAST 4 times as many rays through every pixel.
  160.  
  161. 3.    The reason 2. says MINIMALLY is because of the THRESHOLD parameter.
  162.     This measures the standard deviation in intensity of the COUNT rays
  163.     sent through a pixel. If the SD is greater than the THRESHOLD than
  164.     another COUNT rays are sent... and on and on until either the SD
  165.     falls below the THRESHOLD or you've distributed 128 rays into a pixel
  166.     (maximum).
  167.  
  168. 4.    The results are then averaged to smooth out the "jaggies".
  169.  
  170. This is why there is a Z command to show you how much anti-aliasing actually
  171. had to be done.
  172.  
  173. ->    Just out of interest what do you do for a living and where did
  174.     you go to school?
  175.  
  176. Head of AI tools for Digitial Equipment Corporation Database Systems Advanced
  177. Development. Carnegie-Mellon Univ. (BSEE & MSIA).
  178.  
  179. ->    I notice code for CYLINDER objects in RAY, why aren't they documented?
  180.  
  181. Cylinder was never completed (sorry). 
  182.  
  183. ->    What happens if two objects occupy the same space?
  184.  
  185. Which ever one is "sorted" first will be visable (pretty random).
  186.  
  187. ->    Can you give me a picture of the coordinate system?
  188.  
  189. It's a little difficult to draw a picture of the coordinate system, but I'll
  190. try using an example where the eye is at 30,180,200 and the direction vector is
  191. -50,-320,-350. If you add these two points you get the focus point
  192. (-20,-180,-150). At the focus point there are +- 128 units in X and +- 85 units
  193. in Y. Here is the result (anything inside of the "viewing cone" is visable):
  194.  
  195.         EYE        SCREEN    FOCUS POINT___---
  196.                        ___---
  197.          (-73,-48,0)        ___---|(-148,-265,-150)
  198.                 \ ___---      | :
  199.                ___---|              | :-128 X, -85 Y
  200.          ___---         |57%     100%| :
  201.         <............|............|(-20,-180,-150) 
  202.    (30,180,200)/ ---___         |\(0,0,0)      | :
  203.                ---___|          | :+128 X, +85 Y
  204.                 / ---___      | :
  205.          (+73,+48,0)        ---___|(108,-95,-150)
  206.                        ---___
  207.                          ---___
  208.  
  209. -> What are the maximum and minimum values of each axis?
  210.  
  211. Completely defined by the user. In the example shown above the range of values
  212. (for the axis) are defined by the viewing cone. For example if you move to a Z
  213. of -700, then you have (for a viewable range):
  214.  
  215.     Center of the screen:    ( -70,-540,-700)
  216.     Maximum X,Y:        ( 186,-370,-700)
  217.     Minimum X,Y:        (-326,-710,-700)
  218.  
  219. -> What is the range of the global refraction index?
  220.  
  221. Whatever you want it to be. For example, if you look up the index for glass
  222. you'll find that it is around 1.2, so if you set "N 1.2" everything will look
  223. like it's embedded in glass.
  224.  
  225. -> What does the "a" command actually do?
  226.  
  227. It makes believe that every object is lighted (minimally) by a percentage of
  228. it's natural (diffuse) color. What this means is that the range if from 0 to 1
  229. (100% lighted). A non zero value means (for example) that there is no such
  230. thing as an absolutely black shadow.
  231.  
  232. -> What does the "H" command do?
  233.  
  234. It tints objects according to their distance from the eye.
  235.  
  236. -> What is IDX?
  237.  
  238. The index of refraction (from any physics book).
  239.  
  240. -> What is ambient light?
  241.  
  242. The light comming from all directions at once (background lighting).
  243.  
  244. -> How does diffuse reflection interact with with the color of light sources?
  245.  
  246. Each light sends out rays of blue green and red. The percentage of reflection
  247. is defined by the diffuse amount. So, in a light of red and green a diffuse red
  248. object will appear red while a blue object will appear black.
  249.  
  250. -> How are extents used?
  251.  
  252. The largest amount of time used in a ray tracer is figuring out what items a
  253. ray hits. Normally EVERY object has to be examined to decide this. However, if
  254. you define extents around groups of objects this group will be set aside
  255. (inside an invisible sphere). When a ray needs to be compared with the members
  256. of the group the program will first check if the ray hits the sphere. If it
  257. does not, then NONE of the objects in the group need to be checked. This can
  258. cause a MASSIVE speed up (especially if you have a very complex pixture with
  259. lots of nested extents).
  260.  
  261. -> Why do concentric spheres cause the program to blow up?
  262.  
  263. They don't. It's the one sphere and one quad that have a MIRROR parameter of 1.
  264. (perfect reflection make things go BOOM :-). Use a MIRROR of around .9 and it
  265. works fine. Your guess about infinite reflection is correct. Even though rays
  266. follow the inverse square law, they don't fall off fast enough to prevent stack
  267. overflow with perfect mirroring.
  268.  
  269. -> Who owns the pictures I create?
  270.  
  271. You do. I have NO rights to original pictures created by yourself with
  272. DBW_Render.
  273.  
  274. -> Is there any required order to the items in the .DAT input files?
  275.  
  276. No, do whatever order you feel most comfortable with.
  277.  
  278. -> What format must input numbers be in?
  279.  
  280. Very flexible, 3.0 == 3. == 3 and 0.0 == 0. == 0 == .0
  281.  
  282. Hope these answers help!
  283. Best regards,
  284. dave
  285.  
  286.